Another week, though this one wasn't as fruitful as the last one. My excuse here is that I was overwhelmed with private stuff like acquiring a house and starting with cleaning it up so it can become a home. This is the list for my second week of my stable RC bug squashing:

• 603846: Update LSB header for hal D-Bus activision, not relevant for squeeze.
• 604299: please use KDE 4 port, not relevant for squeeze.
• 608017: XLIB package is not available even after installation, only appears in relation with clisp 2.49.

I know three isn't much, and actually it doesn't impact the list of stable RC bugs not much, we are at 172 open RC bugs against squeeze now. I can only attribute it to that new bugs were filed since, because I am aware that I'm not the only one working on this front, I've been contacted by at least two other people in the last week that are investing some time into this, too. Mostly for self-reference, the highest reported squeeze RC bugs in the list is 618295. This should help me to get a number of newly reported issues (ignoring severity-bump in lower bug numbers). Read you next week!

/debian permanent link Comments: 0 Flattr this

Alright, the stress of the release and its aftermath with respect to the New Website is getting lower. We even were explicitly mentioned for that during the introduction to the category Outstanding Contribution to Open Source/Linux/Free Software at this year's Linux New Media Awards. Given that the Webmaster Team is much more energetic and lively these days I will shift a bit of my efforts to stable RC squashing again. I came to the conclusion that working on lenny RCs doesn't gain much of appreciation or real turnaround, and given that my time is limited I started to switch over to work on squeeze RCs. This is the list of bugs that I squashed last week (actually, marked them as invalid/not affecting squeeze):

• 549054: Still uses gmime2.2, not relevant for squeeze.
• 549056: Still uses gmime2.2, not relevant for squeeze.
• 549057: Still uses gmime2.2, not relevant for squeeze.
• 549058: Still uses gmime2.2, not relevant for squeeze.
• 554310: FTBFS with binutils-gold, not relevant for squeeze.
• 554557 FTBFS: undefined reference to symbol 'gzclose', not failing in squeeze.
• 596569: Depends on xview, not relevant for squeeze.

I hope to be able to keep up that pace for a few weeks (currently there are 168 RC bugs in squeeze listed), and hopefully being able to motivate others to also support our stable release instead of only working on unstable.

/debian permanent link Comments: 0 Flattr this

I guess it won't be very many people reading this blog to know the name, even though he was without any doubt one of the biggest entertainers. Lots of movies, his own TV show, and an enormous amount of albums made him well known far outside the borders of Austria, his home country. Last saturday he died in the age of 84, yesterday was his funeral. This is a special dedication to him. Peter, you will be missed.

• Die s esten Fr chte (1952): He was still rather young at that time but it already shows his great talent, both in acting and in singing.
• Mamma di Mandolin (1956): Another great excerpt from a movie in which he starred.
• Dankesch n: Thank you.

Servus.

/music permanent link Comments: 1 Flattr this

Debian unstable is not conceived as a product for end-users, and for very good reasons. There seems to be some misunderstanding and people trying to push end-users to use unstable. This blog post tries to address the claims raised and put them into proper light. 1. It contains mainly stable versions of the software The critical part here is the term mainly. Yes, developers are advised to only upload packages to unstable that they deem to be suitable for the next stable release. This is no hard requirement though and no one actually playing a gate-keeper enforcing this recommendation. Also, there is a fine amount of packages that follow either VCS snapshots or development branches, and only time can tell how stable those releases actually are. That's actually why there is a delay of several days before a package can transition over to testing. 2. It doesn't break badly every other day That's right but if you look at it, it also means that it does break badly eventually. And if you don't know how to move on from there, including knowing the location of maintainer scripts and how to edit them in those cases, or even resort to a rescue system, you are in troubles. 3. It's the basis of other distributions That's right in itself too, but it doesn't address the fact that those other distributions do put a lot of effort into quality assurance to work around the most nasty and annoying bugs that do affect unstable every other day. 4. It's not inherently less secure than Stable or Testing It's not inherently more secure than stable or testing either. And this is also ignoring the fact that some security bugs don't even get into stable or testing, they only affect unstable and have to get addressed just there. 5. I use it on my main computer This is the reason that you should ignore as most. People using unstable are often enough deeply involved into Debian maintenance, know how to write maintainer scripts, know where they are located in case of troubles, know how to use a rescue system in case of bootloader or kernel troubles. Just think about whether you would consider yourself to be at the same knowledge level than the person who wrote the blog article you read that used this as a convincing argument. Conclusion: Stories always have several truths attached to them. If you feel adventurous, like to understand what's going on and have a tendency for digging into things that go wrong, you most probably are using unstable already anyway and are reporting bugs that you find along your way. If you on the other hand rather just want to use your computer and don't want to work around (smaller) bugs every other day, you rather should stick with the release that is actually provided as purpose to suit the needs of end-users: stable.

/debian permanent link Comments: 19 Flattr this

It's been over a month already since I last suggested a band, this is overdue. Today because of a discussion this band came back into my mind and I want to share it with you: The Chemical Brothers. So without too much further talking here are the songs:

• Galvanize: This song got me into love with the band, and it still is a great motivation push.
• Hey Boy Hey Girl: An older song of theirs which might also be well known.
• The Test: It's not just a nice song but also a terrificly great video!

Enjoy!

/music permanent link Comments: 1 Flattr this

On 24th of October we've been to the concert of Unheilig. It was actually very touching, even though the sound quality of the venue was disappointing. Here are the common three songs that I usually share about bands that I like to introduce you to:

• Mein Stern: Even though it's not my star in those pictures, the song still gives me goose bumps.
• Geboren um zu Leben: He wrote this great song for his best friend that isn't anymore.
• An deiner Seite: Another truly great of their songs. Let it touch your soul.

I am aware that these songs are all pretty emotional and rather quiet. Unheilig has also a much harder side to them. It's just that my current mood is pretty emotional, that's also the reason for this selection.

/music permanent link Comments: 0

Like you most likely know, I've been at the openSUSE Conference last week. I've been representing Debian through a talk about Debian - The Project and its Resources, covering services and resources that are usable and useful for other distributions too. The invitation to submit talks were sent to various projects and distributions because of the set topic on Collaboration across Borders for the conference. My impression was that very few distributions have followed the invitation, I am only aware of some Fedora people that have attended. Vincent Untz from GNOME gave a combined keynote with Cornelius Schumacher from KDE. The abstract of my talk and the slides are available from the conference website. The talk was well received and interested people also asked about some of the services like how our buildd network works, or whether the screenshots service has support for localized images too, or if it would be expandable for more general usage of non-Debian based distributions. One topic raised was with respect to the whohas tool: A mapping layer/tool/database for package names. We divert from upstream naming schemes for consistency reasons, like with our library, Perl and Python naming schemes. Other distributions have similar approaches but a different naming scheme. To make inter-distribution tools really useful it would require to have some layer that is able to map the package name from one distribution to another one. One idea for it that was thrown in was to use upstream homepage, but not all packages do have proper homepages, some only live in some git repository, others would either like to link to sourceforge's project page instead of the project's homepage, and other tricky issues. Something unique is clearly called for here and needed to get stored in the package's metadata. Apart from my talk and the occasional mentioning of openSUSE is on my desktop, but I run Debian on my server I noticed that the beverage of openSUSE is their own beer. Taste is a tough topic, personally I rather prefer our Debian wine. And I missed the chance to seduce them into playing Mao, I forgot to bring playing cards along. I hope to get a second chance at anoter event.

/debian permanent link Comments: 3

Within the next few days there will be the openSUSE conference held in Nuremberg/Germany. The topic of the conference was set to Collaboration Across Borders and along that theme they invited other distributions to submit talks. Given my involvement with the Derivatives Frontdesk zack asked me whether I'd like to submit a talk proposal. I usually have a hard time to refuse such questions this will actually happen. My talk will be in the Distributions Track on Thursday afternoon, the topic is Debian The Project and its Resources. The resources that I will cover are those that can be very useful to other distributions too, and last Thursday I tested the talk at our local Debienna Meeting, gathered further ideas and feedback to cover in the talk. Thanks to you, guys! Unfortunately contrary to what we are used to in Debian (extraordinary thanks to the Video Team!!!) there will be no streaming or recording of the talks from what I was told, so you have either to hurry to be there, or be satisfied with the slides I'll put up after the talk. It's the best I can offer. See you around!

/debian permanent link Comments: 5

I wrote the following as a foreword for the great German book Open Source Projektmanagement that Michael Prokop wrote. Unfortunately the foreword didn't manage it in time into the book because of various circumstances. As I'm not a person to throw away already written material, here is it for your reading pleasure. Maybe it makes you consider obtaining a copy of the German language book for yourself!

The Whole is more than the Sum of the Parts When I first met Mika at a Linux conference some years ago I quickly noticed that he had potential. The way he asked questions and tackled issues did impress me. We did meet again at various events, joined forces in various projects and knew that the result would be good. Back in the year 2004 the only real live CD was Knoppix. It always was too sluggish for me because I never really liked KDE and also OpenOffice.org was too bloated for me. I was working since a year at an Internet provider, felt comfortable in the shell and was missing the tools on Knoppix which I used daily. Often enough the frustration with the status quo starts the best projects. And so I had the idea spinning around to start a sysadmin live CD. There was just one problem here: Exactly at the same time Mika had already started such a project. And I knew one thing: it would had been a lost race to compete with him in creating the better live CD. So I joined his team and helped with the best of my knowledge. The name choice alone showed that he was the right person for the job: Grml an expression of the frustration that even he felt which spoke directly to the heart of so many. But it wasn't just the chosen name that showed that Mika was the right person for the job of the project leader. It's always the sum of the parts, no matter how minor they might look. He quickly managed a first release and in light of that also created an event which was fitting for the release of the first version: the OS04 an Open Source event which managed to get Jon Maddog Hall as keynote speaker. Mika managed through his welcoming way to lure more people into helping out. The team grew over the years, further regular releases increased the fan base, not only through the creative release names which are surely one of the parts that helped create the success. He always was open to suggestions for new tools that helped to extend the project. The lived openness did lead among other things to the case that other live CDs started to use the grml build system. JUXlala 2.0 (the system for preschool kids) is just one example. Why do I write primarily about Grml, one could get subliminal advertising probably cheaper? I do it because Grml is an extremely good example of the experience revealed in this book. And even though every project is different, it is still exactly the sum of the parts that leads to the success of a project. And exactly these parts are covered in this book and can be considered for the project at hand and get implemented accordingly. Good luck whether in large or small.
Rhonda

/debian permanent link Comments: 0

People start to wonder why the timeouts for the passwords in sudo seem to be so short recently in squeeze. The reason is a change in the defaults that causes it. The following option changed its default:

tty_tickets

If set, users must authenticate on a per-tty basis. Normally, sudo uses a directory in the ticket dir with the same name as the user running it. With this flag enabled, sudo will use a file named for the tty the user is logged in on in that directory. This flag is on by default.

To change it back you can add this line into your sudoers file:

Defaults !tty_tickets

Please be aware that the change in default is done because of security considerations. You might not always have all the ttys you are logged in directly visible and others might be able to access them (like, sudo on a remote SSH session). Use with caution, you though might consider disabling it on local systems with no remote users. Hope that helps! Actually this blog post was triggered by a question on ask.debian.net, a new service in the Debian eco system.

/debian permanent link Comments: 1

The Backports Team is pleased to announce the availability of a new suite on backports: lenny-backports-sloppy. Please read carefully before considering using or uploading to it what this entails. The Background You might want to ask: What's that? Let me explain it. During the etch release discussions popped up on the backports list with two clashing groups:

• One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
• others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.

The standing at that time was to accept packages that were in testing after the release, which wasn't etch anymore but lenny. The same discussion started again before the lenny release, and given that we are facing the upcoming squeeze release we started internally to discuss how to noise down these long and tedious discussions, because both groups of people had valid opinions that shouldn't get ignored. So this is where the idea for lenny-backports-sloppy comes from. The Change lenny-backports-sloppy will please the group that is happy to upgrade from lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is meant only for packages from squeeze, even after the release. Technically that means it will get locked down for uploads after the release of squeeze and require manual approval (for e.g. point release update versions, or security updates that happen during the squeeze release cycle), while lenny-backports-sloppy will accept packages from wheezy. Uploading to lenny-backports will have to get approved by the Debian Backports Team after the squeeze release, just like uploads to lenny are currently approved by the Release Team. While lenny-backports-sloppy is created already and working we ask you to not upload packages there without prior discussion with the Backports Team. This is meant to ensure that the Uploader is aware about the expectations that come along with that: The package should have a good chance to get included in the next Debian release aka wheezy, and that the Uploader is willing to look after the package in the upcoming squeeze-backports suite after the release of squeeze to ensure upgradability. In case of questions, feel free to ask either directly on the debian-backports@lists.debian.org mailinglist, or contact team@backports.debian.org privately. We are also pleased to announce that the first upload to lenny-backports-sloppy already happened. From now on you will be able to install Postgresql 9.0 (which is not targeted at squeeze) from lenny-backports-sloppy. How to use If you want to use lenny-backports-sloppy you will have to add both lenny-backports and lenny-backports-sloppy to your sources.list. Backports from lenny-backports-sloppy may depend on packages in lenny-backports.

  deb http://backports.debian.org/debian-backports lenny-backports   main
  deb http://backports.debian.org/debian-backports lenny-backports-sloppy main

About Backports You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in. Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. It is recommended to pick out single backports which fit your needs, and not to use all available backports. Thanks for reading this far, and enjoy!
Rhonda in the name of the Backports Team

/debian permanent link Comments: 1

If I'll make it through this week it's because of these special people in my life. They help me through thick and thin, they believe in me, they are there for me. There is one universal term for them, friends. The term in its real meaning, in its original meaning, not in the perverted sense that sites like Facebook want to make you believe that it's alright to apply to random bystanders. You won't go as far for those as you'd go for your true friends, so don't let them steal away the meaning of the word from you. As music is one of the most driving force for me and this song makes me wanna cry, this is what I want to send out to my friends who are able to motivate me to keep me going: That's What Friends Are For. And as this song is so special I won't drown it in two more like I usual do, this blog entry goes to my personal section anyway. There is though a second video of a live version of it that in my opinion adds quite something to it, it contains a short interview with Dionne Warwick at the end. Enjoy!

/personal permanent link Comments: 2

I guess it's time again to push for another band. This time I present you Garbage. I love them, but one has to be careful in what mood one is when listening to them; it's possible that they move you in a direction you don't feel comfortable with at that time.

• Bleed Like Me: If you listen closely to the lyrics of the second verse you might get an idea why had to love that song.
• The World Is Not Enough: One might argue that a band has made it when they do a James Bond title song. This is it.
• Only Happy When It Rains: Probably the best known song from Garbage. Damn fine, great tune and groove for the message it contains.

Enjoy!

/music permanent link Comments: 0

It is a while since we managed to get below the 1000 stable RC mark. Last weekend we managed the next mark, that is we are below 900 now! Obviously my effort during the RCBC did take us a fair step in that direction, but I don't want to take full credit for it. The last bit that got us below the 900 happened through an event of last weekend: The current point release of lenny. Be aware that the BTS doesn't know about proposed-updates, so bugs closed through uploads to there only are seen when they hit the main pool which is the reason for point releases. It were something around 25 RC bugs that were closed by that. I haven't checked who exactly is to thank here, but looking at the non-DSA packages one finds some perl packages and at least two font packages. Thanks to the corresponding teams for their help! I plan to continue these efforts, so if you think it's a good idea you might want to flattr it. I think this quote sums up the motivation behind this pretty well:

<jwilk> Yay, only 900 bugs to fix and we can release lenny! Oh wait...

/debian permanent link Comments: 0

I started to give flattr a try, too. It is a social micropayment site and the similarity of its name to the verb flatter is on intention. It is meant to say thanks in small amounts month by month to "things" you like. One such thing I created is my blog you can find the link to it below every entry. To be able to flattr someone one needs to create an account on the site and put money into their account. After that it's possible to follow the flattr button links. If you are reading my blog on my site and have JavaScript enabled you just have to click the flattr part of the image (not the number) to do so. If you are reading it through my feed or with JavaScript disabled you will have to click a second time on the flattr site to make the flattring happen. Another thing I've created is Debian BTS: cleaning up. I use this link in my mails to the Debian BTS for my stable RC cleanup efforts, or general proper closing of bugs that aren't getting archived. Through the help of UDD I've created me helpful overview pages of bugs that need attention for this. The third thing I've created is Package Maintenance. If you are a fan of one of the packages I maintain and want to thank me for taking proper care of it, feel free to also click this one. Please be aware that this shouldn't be seen as an Upstream appreciation if one of the projects I package for Debian uses flattr themself then you should definitely (also) consider flattring them for their own. About Upstream projects that use flattr: One of the packages I invest quite a lot of effort into started using flattr: wesnoth. They have put the flattr button on their entry page at wesnoth.org, here is the direct link to their first and general thing: The Battle for Wesnoth. Please be reminded that the things you did flattr in a previous month can again be flattred the next month. This is especially true for general purpose things like what I am using currently. Others might create things for every single blog entry, or very specific tasks, to allow people to flattr them more often in a month and get a bigger share of the cake. So keep in mind which things are general ones and consider returning to them. Enjoy!

/debian permanent link Comments: 1

People often want to know what an application looks like before they install it. This is one of the reason why Christoph Haas started with the screenshots.debian.net service. People can upload screenshots for their favorite applications for others to take a look at. Finally, as convenience feature, they are now added on packages.debian.org. When you click on the screenshot of a package you can see the list of all of the available ones. In the case when no screenshot is available yet the page will show a placeholder image which gives you a convenience link to the screenshots page of the package where you can submit one for the benefit of all. Please make sure that you are following the guidelines for submissions, otherwise your upload might get rejected. On a not totally unrelated topic, the packages.ubuntu.com site finally will also show you packages in maverick. It doesn't show screenshots yet if you think adding support for screenshots in there would be a good thing too, please let me know! Enjoy!

/debian permanent link Comments: 5

A while ago I was with my SO at a concert of a band I might cover at a later point. This time I want to cover the support act of that concert: Jerboa. It was a bit weird to see a single person on stage turning some knobs, but he quickly caught both our attention and heart. And he was a charm to talk with afterwards when we bought his CD. He's definitely worth your attention, and if you are able to see him live take the chance for it.

• Number 1: The obvious number 1 song in the list. Perfect groovy song, great video too.
• Running North (remix): Also interesting output of his creativity.
• Just Another Number: It starts off pretty smooth but then really kicks in. Hard to not headnick along to the song, it is far away from being Just Another Number.

Actually I would have loved to include What if in the songs but unfortunately that one wasn't available so I had to look for a replacement for it. Enjoy!

/music permanent link Comments: 2

Happy 17th Birthday, Debian! You kept me busy for the last 10 years and I am really looking forward to what the next 10 years might bring for our relationship. Thanks also to all the people who also are able to keep calm and to the point when discussions turn to get heated. You are the ones who make work on Debian enjoyable. Also a lot of thanks to all the people that understand the power of positive encouragement like what is currently flowing in through the thank.debian.net website. Likewise much thanks to the ever growing number of distributions that are based on Debian, because doing that is a very special kind of appreciation of our work. Thank you all!

/debian permanent link Comments: 0

This blog post is actually a response to a talk that was given at the debconf last week. It was marga's talk about Making Debian Rule, again. Now that the beta versions of the talks are available for download I'm able to proper quote what I want to respond to: Is there a reason why we haven't yet updated the website?, perhaps someone can answer. I feel the need to respond to this as I am the main person driving that effort. Unfortunately the question was asked in a talk with no-one involved in that work around instead of addressing those people directly, and the question wasn't brought to my attention before the talk so that I could have provided an answer to offer in the presentation already. Also, as disclaimer, this is my personal story for it and doesn't need to get shared by the other people involved. I hope it can be seen as an answer anyway. As a little of background, Kalle's proposal went a long path before even I found out about it. I was simply in awe in several ways about it because it wasn't just a great mockup of the page (which it actually is, IMHO) but was accompanied by thoughts about not only the main site but also about several sub sites. Also, it was accompanied by patches, so it was seemingly ready to get deployed right ahead. I started working on it, got accused of being discouraging while doing that, got told that it would require a proper vote for a decision and can't happen just as, but those are just the Debian way of communication. I nevertheless did set up several test sites for some over the time to play with it. Some did work out better (like the git one, though this one came last and Kalle improved the CSS over time a fair bit), some weren't ready yet (like wiki, missing e.g. the coloring for the version diff, or the packages one where the separation between the different sections isn't that visible yet). Time passed, other things demanded their attention too. Like the thing where our system administrators did send me a request along about a new www-master server that needs to get set up from scratch. Given that the documentation about the required packages for the website was lacking a fair bit (to say the least) it did require a lot of attention, especially when doing things from scratch the wish to document the dependencies properly is just natural. There are still some issues with that as can e.g. be seen on this page in the empty table at the bottom. The same issue also appears on my testsite for the new design. The last part though is currently the biggest blocking issue for both efforts. There is no way to move forward with either without having that addressed. Simon Paillard did a great job on helping the move along so far, keeping the thread about the server move requirements that I started on the debian-www mailinglist updated with information about what's still pending. Unfortunately Kalle, Simon and me are also facing some private time constraints (amongst other duties that require attention) which weren't helping to move forward at a bigger pace. Unfortunately not very many people actually has shown interest in helping out neither, after all it's easier to go and ask questions about why it's not done yet to the completely wrong audience. My plan is to switch many sites at the same time instead of one after the other simply for the effect but also for less distraction for our users, including less people repeatedly pestering about when this or that site gets done, too. At least we need a final discussion on what should go into the header links and what should be at the bottom before a switch can be made anyway. And for some there is still the opinion that such a switch is nothing that we are rightfully allowed to decide without a vote, so that's also part of the reason to not just deploy it. I hope this answers the question to some extend and like said, if only I would had been addressed about this before the talk was given an answer to it would had been ready for presentation right ahead instead of having a pretty terse statement getting relayed through IRC (thanks, Yoe!) because I was fortunate enough to be around and watching the talk at that time. Feel free to discuss it further or offer your help on debian-www, especially if you are familiar with working on CSS files.

/debian permanent link Comments: 3